AWSで優れた設計をしているか？の質問と回答（コスト最適化編）「AWS Well-Architected Framework」

「AWS Well-Architected Framework」

昨年、AWSより「AWS Well-Architected Framework」というドキュメントが公開されました。この文書は、みなさんがより良いクラウドベース設計を評価改善し、設計によるビジネスへの影響についてより良い理解をするためのものです。AWSで良い設計をしているかを定義する柱として、4つの分野におけるベストプラクティスとガイドを定義し、一般的な設計指針について取り組みます。

今回はコスト最適化についての確認事項をご紹介します。

他の確認事項はこちらです。

AWSで優れた設計をしているか？の質問と回答（セキュリティ編）「AWS Well-Architected Framework」
AWSで優れた設計をしているか？の質問と回答（信頼性編）「AWS Well-Architected Framework」

4つの柱

「AWS Well-Architected Framework」で示されている4つの柱は以下のとおりです。

1. セキュリティ（Security） リスクの評価・軽減戦略によって、ビジネス価値を提供しつつ、情報・システム・資産を保護する能力について
2. 信頼性（Reliability） インフラやサービスの障害から回復する能力、要求を満たすだけのコンピューティング資源を動的に獲得する能力、および設定ミスや一時的なネットワークの問題などから生じる混乱を軽減する能力について
3. パフォーマンス効率（Performance Efficiency） システム要件を満たすために効率的にコンピューティング資源を利用する能力、および需要の変化や技術の進化があっても、その効率を維持する能力について
4. コスト最適化（Cost Optimization） 最適ではないリソースや不要なコストを回避または取り除く能力について

質問＆回答とベストプラクティス（コスト最適化編）

COST1 : いかにして必要なキャパシティが過不足なく割り当てられるようにするか？

費用と性能の点でバランスが取れたアーキテクチャを維持するには、利用費を払っているリソースはちゃんと使われていることを確実にすべきです。あまり利用されていないインスタンスがないようにしてください。 誤った利用分析は運用コストの面でもAWSへの支出への面でもビジネスに悪いインパクトを与えます。

☆ベストプラクティス

• 需要ベースのアプローチ。変化する需要に対してAutoScalingで対応する。
• キューベースのアプローチ。タスクをSQSキューに入れ、必要に応じてインスタンスを増減させる。
• 時間ベースのアプローチ。日中だけ起動する、週末は開発/テスト環境を落としておく、Black Friday等のイベント時に増設する。
• 適切な割り当て。DynamoDBやEBS(provisioned IOPS)、RDS、EMR等のサービス利用時に適切なスループットや容量を割り当てる。

COST2 : いかにしてAWSサービスの利用を最適化するか?

もし、アプリケーションレベルのサービスを使うなら、上手に活用するよう心がけてください。 例えば、S3の利用量をコントロールするためにライフサイクルポリシーを使う、RDSやDynamoDBを利用し柔軟性を手に入れる、という具合です。RDSの場合、Multi-AZが有効になっているか、DynamoDBの場合Provisioned IOPSが適切か確認してください。

☆ベストプラクティス

• サービスの特性に沿った最適化。例えば、EBSへのIOを最小化する、S3に小さなファイルを大量にアップロードしない、EMRにはスポットインスタンスを利用する、等々。

COST3 : コスト目標に合った適切なリソースを選択しているか?

タスクに対して適切なEC2インスタンスを選択しているか確認してください。 選択したインスタンスタイプがワークロードに対して適切であるか調べるため、ベンチマークを取ることを推奨しています。

☆ベストプラクティス

• ニーズにあったインスタンスタイプの選択。例えば、ワークロードにあったインスタンスタイプ(コンピュートインセンティブ、メモリインセンティブ、ストレージインセンティブ)。
• サードパーティー製品の利用。例えば、CopperEggやNewRelicを利用し、適切なインスタンスタイプを決定する。
• CloudWatchを利用し、CPU負荷等を測定する。
• CloudWatchのカスタムメトリクスを利用し、メモリ使用量を測定する。
• アプリケーションをプロファイルする。プロファイルの結果をもとに、EBSのタイプ(magnetic、general、provisioned IOPS)やEBS-Optimizedオプションの有効化を決定する。

COST4 : コスト目標に合った適切な価格モデルを選択しているか?

支出を最小にするため、ワークロードにあった適切な価格モデルを採用してください。 最適なのはすべてオンデマンドインスタンスを利用することかもしれません。もしくは、オンデマンドとリザーブドインスタンスの混成か、あるいは適切であればスポットインスタンスを使っても良いかもしれません。

☆ベストプラクティス

• スポットインスタンス。ある種のワークロードに対してはスポットインスタンスを利用する。
• 利用分析。リソースの利用量を常に分析し、その結果を受けてリザーブドインスタンスを購入する。
• リザーブドインスタンスの売却。必要なリソースに変更があった場合は、不要なRIをリザーブドインスタンスマーケットプレイスで売り、必要なRIを購入する。
• 自動化。可能であれば利用されてい無いインスタンスを停止する(AutoScaingを利用し、営業時間以外はスケールインする)。
• コストの検討。リージョン選択の際、コストも考慮に入れる。

COST5 : ROIを改善するために利用できるマネージドサービスはあるか?

EC2やEBS、S3はブロックのようなサービスです。一方、RDSやDynamoDBのようなマネージドサービスはより高いレベルのAWSサービスです。これらのマネージドサービスを利用することで、管理や運用にかかるオーバヘッドをかなり削減でき、アプリケーションやビジネスに結びついた活動に注力できるようになるでしょう。

☆ベストプラクティス

• サービス検討。アプリケーションレベルのサービスを検討し、利用できるものを探す。
• 適切なデータベースの検討。適切であればRDSやDynamoDBを利用する。
• 他のアプリケーションレベルサービスの検討。SQSやSNS、SESなど
• CloudFormation、Elastic Beanstalk、AWS Opsworksの検討。標準化とコスト管理のため。

COST6 : どのようなアクセス管理と手順でAWSの利用を管理しているか?

ビジネス目標を達成しつつ、支払われているコストが適切か確認できるような方針と手順を確立すべきです。タグ付けとIAMによる管理を通して、チェックアンドバランシングを行うことで、無駄な費用をかけることなく刷新を続けることができます。

☆ベストプラクティス

• グループと役割の設定(開発/テスト/本番等)。IAM等を利用し、各グループ内でインスタンスやリソースを起動できるユーザを管理する。(EC2以外のAWSサービスやサードパーティー製品も同様。)
• プロジェクトのライフサイクルを追跡する。プロジェクトやチーム環境のライフサイクルを追跡、測定、監査し不要なリソースへの支払いを避ける。

COST7 : どのようにして利用量と支出をモニタリングしているか?

コストを監視し、管理し、適切に分配するための方針と手順を確立すべきです。 AWSが提供するツールを活用し、誰が、何を、どのくらいのコストで利用しているか明確にしてください。 それにより、ビジネスに必要なものとチームのオペレーションについてより深く知ることができるでしょう。

☆ベストプラクティス

• すべてのリソースへタグ付け。インフラおよびその利用量の変化と支払いの変化を関連付ける。
• Detailed Billing Reportsのレビュー。Detailed Billing Reportsの確認を標準的な手順とする。
• コスト効率の良いアーキテクチャ。利用量と支出の双方について計画を作成する(単位あたりの費用を算出: 例、ユーザあたり、データ量あたり)。
• モニタリング。CloudWatchやサードパーティー(Cloudability、CloudCheckr)を利用し、常に利用量と支出を監視する。
• 通知。あらかじめ決められた上限を超えた支出があった場合は、主要なメンバーに知らせる。
• AWS Cost Explorerの利用。
• ファイナンス主導のチャージバックメソッドを利用し、インスタンスやリソースをコストセンターに配分する(タグ付け等)。

COST8 : 不要になったリソースの破棄、もしくは一時的に利用され無いリソースの停止を行っているか?

使われているサービスにだけ支払いが発生していることを確認してください。 プロジェクトの開始から終了まで変更管理とリソース管理を行うことで、手続き上、変更や拡張が必要になった場合は変更/拡張すべき箇所を見つけることができるでしょう。 ワークロードに対して最適なプロジェクトにするため、AWSサポートを活用してください。AWSの各種機能、例えば、AutoScaingやAWS OpsWorks、AWS Data Pipline、他のEC2のプロビジョニング手法はどのような場面で利用すべきかについてサポートの助言を活用してください。

☆ベストプラクティス

• 不要なインスタンスもしくはあまり利用されてい無いリソースを特定し破棄する際に、破棄しても影響がでないようにシステムを設計する。
• 孤立したリソースを特定し破棄するプロセスを作る。
• システムと手順に基づいて破棄されたリソースに矛盾がないようにする。

COST9 : アーキテクチャ設計時にデータ転送費用を考慮したか？

データ転送費用を監視し、転送費用を減らせるような設計を行えるようにしてください。 例えば、コンテンツプロバイダの場合、S3から直接コンテンツ配信しているのであれば、CDNであるCloudFrontを使うことでかなりコストを削減できます。 小さいが効果的な設計の変更が劇的に運用コストを下げる場合があることを覚えておいてください。

☆ベストプラクティス

• CDNの利用。
• データ転送を最適化する設計(アプリケーション設計、WANの利用等)。
• 状況によってはDirect Coneectを利用することでコスト削減と性能を向上させる。
• データ転送費用と可用性、信頼性要求をバランスさせる。

COST10 : 新サービスをどのくらい活用しているか?

AWSの目的はユーザが最適でコスト効率の良い設計をする手伝いをすることです。 新しいサービスや機能はすぐにコストを下げるかもしれません。Amazon Glacierは良い例です。コールドデータつまり滅多にアクセスしないがビジネス上もしくは法律上の理由で保持し続けなければいけないデータを低いコストで保存できます。 別の例としてS3の低冗長化ストレージがあります。冗長性を低める代わりにコストを下げることができます。

☆ベストプラクティス

• AWSソリューションアーキテクトやコンサルタント、アカウントチームと定期的にミーティングし、どの新サービスや機能がコスト削減のため利用できるか検討する。

まとめ

最適なコストでシステムを構築、運用するために確認すべき事項について紹介しました。
コストの最適化はシステム構築時だけではなく、その後の運用フェーズでも継続的に行うことが重要です。
状況の変化によってシステム内で必要とされるリソースの量や配分も変化するからです。また、AWSの新サービスを導入することで、より低いコストでシステム内の機能を実現できるようになるかもしれません。
継続的なコスト最適化によりコスト効率の良いシステムを維持するようにしましょう。

参考資料

Are You Well-Architected?